X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8DE57.3FA2AD48@onstor-exch02.onstor.net>; Fri, 4 Jul 2008 21:26:09 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C8DE57.3FA2AD48"
Content-class: urn:content-classes:message
Subject: RE: NDMP performance
Date: Fri, 4 Jul 2008 21:26:09 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E12C027@onstor-exch02.onstor.net>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: NDMP performance
Thread-Index: AcjdxEnP4sOBBqBFRxGb0OpjqI8aywACkWqgAAEJrXAAF0bVUAAJcyz6
References: <BB375AF679D4A34E9CA8DFA650E2B04E0ABCF774@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0ABCF792@onstor-exch02.onstor.net>  <2779531E7C760D4491C96305019FEEB514A18136E5@exch1.onstor.net>
From: "Narain Ramadass" <narain.ramadass@onstor.com>
To: "Xian Hong" <xian.hong@onstor.com>,
	"Shin Irie" <shin.irie@onstor.com>,
	"Tim O'Callaghan" <tim.ocallaghan@onstor.com>
Cc: "dl-cstech" <dl-cstech@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8DE57.3FA2AD48
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C8DE57.3FA2AD48"


------_=_NextPart_002_01C8DE57.3FA2AD48
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Some answers inline (prefixed with CRN):


-----Original Message-----
From: Xian Hong
Sent: Fri 7/4/2008 5:27 PM
To: Shin Irie; Tim O'Callaghan
Cc: dl-cstech
Subject: RE: NDMP performance
=20
I've found a ndmp real case. "AER"

=20

Bobcat2

SN: 0508040014

Data warehouse: =
http://cs-web/data/bysn/050/0508040014,onstor2,aer_atmospheric_environmen=
tal_research,_inc./

Volume: Project

Size: 3.6TB, 459857931 Blocks

iNode: 4.3M

Elog:

Jun 29

 =
http://cs-web/data/bysn/050/0508040014,onstor2,aer_atmospheric_environmen=
tal_research,_inc./elogs/2008/06/messages.20080629.gz

Jun 30

http://cs-web/data/bysn/050/0508040014,onstor2,aer_atmospheric_environmen=
tal_research,_inc./elogs/2008/06/messages.20080630.gz

=20

Elog digest:

=20

Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1276: FS: project      =
0x21700000098 - dumpStart - dump_restore - dump progress[11]: total =
records: 41415283; dumped: 4128611; remaining: 37286672; estimated time =
remaining: 13:44:12; percent complete: 9%; throughput: 46325760 bytes =
sec=20

Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1276: FS: project      =
0x21700000098 - dumpStart - dump_restore - dump progress[11]: total =
records: 41415283; dumped: 4128611; remaining: 37286672; estimated time =
remaining: 13:44:12; percent complete: 9%; throughput: 46325760 bytes =
sec=20

Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1277: FS: project      =
0x21700000098 - dumpStart - dump_restore - [11] dump LOG message: Sun =
Jun 29 16:02:10 2008 dump progress[11]: total records: 41415283; dumped: =
4128611; remaining: 37286672; estimated time remaining: 13:44:12; =
percent complete: 9%; throughput: 46325760 bytes sec  =20

-----

-----

Jun 30 08:58:23 onstor2 : 1:3:efs:INFO: 2248: FS: project      =
0x21700000098 - dumpStart - dump_restore - [11] dump LOG message: Mon =
Jun 30 08:58:23 2008 dump progress[11]: total records: 41415283; dumped: =
37345883; remaining: 4069400; estimated time remaining: 2:2:26; percent =
complete: 90%; throughput: 34037760 bytes sec  =20

Jun 30 08:58:23 onstor2 : 1:3:efs:INFO: 2248: FS: project      =
0x21700000098 - dumpStart - dump_restore - [11] dump LOG message: Mon =
Jun 30 08:58:23 2008 dump progress[11]: total records: 41415283; dumped: =
37345883; remaining: 4069400; estimated time remaining: 2:2:26; percent =
complete: 90%; throughput: 34037760 bytes sec  =20

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2846: FS: project      =
0x21700000098 - dumpSetup - dump_restore - [26]: client id 1214628720 =
snapnum 0 path / dumpRootInum 2 recSize 61440 lastDumpTime Mon Jun 30 =
23:30:16 2008 vol id 0x21700000098

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2846: FS: project      =
0x21700000098 - dumpSetup - dump_restore - [26]: client id 1214628720 =
snapnum 0 path / dumpRootInum 2 recSize 61440 lastDumpTime Mon Jun 30 =
23:30:16 2008 vol id 0x21700000098

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] (start dump time =
1214884511 secs)

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] (start dump time =
1214884511 secs)

Jun 30 23:58:11 onstor2 : 1:3:efs:NOTICE: 2855: project snap create =
complete for dump_26 id 4

Jun 30 23:58:11 onstor2 : 1:3:efs:NOTICE: 2855: project snap create =
complete for dump_26 id 4

Jun 30 23:58:11 onstor2 : 1:2:efs:INFO: 2856: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] dump LOG message: Mon =
Jun 30 23:58:11 2008 mapping (Pass I) [regular files] =20

Jun 30 23:58:11 onstor2 : 1:2:efs:INFO: 2856: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] dump LOG message: Mon =
Jun 30 23:58:11 2008 mapping (Pass I) [regular files] =20

=20

I'm confused with these logs and have some questions:

1.       How to interpret NDMP log messages? Is there any documents?=20
CRN: The messages are mostly self-explanatory. They indicate dump =
progress. Please note that multiple NDMP sessions may run at the same =
time - even on the same volume if they are partial and which is how LSI =
seems to do it - these have to be appropriately interpreted. Also, =
please note that none of these statistics was meant to be dead-on =
accurate - most of them approximate at best. There is also a low =
priority bug open about the stats being off under specific =
circumstances.

2.       There is no start NDMP log messages and end log messages in the =
elogs.=20

The first message is as below, but is not start message.

Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1276: FS: project      =
0x21700000098 - dumpStart - dump_restore - dump progress[11]: total =
records: 41415283; dumped: 4128611; remaining: 37286672; estimated time =
remaining: 13:44:12; percent complete: 9%; throughput: 46325760 bytes =
sec=20

                And the last message is as below, but is not end =
message.

Jun 30 08:58:23 onstor2 : 1:3:efs:INFO: 2248: FS: project      =
0x21700000098 - dumpStart - dump_restore - [11] dump LOG message: Mon =
Jun 30 08:58:23 2008 dump progress[11]: total records: 41415283; dumped: =
37345883; remaining: 4069400; estimated time remaining: 2:2:26; percent =
complete: 90%; throughput: 34037760 bytes sec  =20

=20

                According to =
http://wiki.onstor.net/wiki/Troubleshooting_NDMP,

=20

Alternatively, you could also search for start dump in the elogs to get =
dump start time. Note the volume name. Then search for dump is complete =
to get the end time and match the volume name. Obviously if you don't =
find the end of the dump, it was still running when the stats were =
collected.

                But there is only a start dump messages after a series =
NDMP process log messages.

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] (start dump time =
1214884511 secs)

               =20

CRN: Since these large filesystems take a lot of time to dump, it is not =
uncommon to find NDMP running for days. Alternatively, it is possible =
for the elogs to roll over just after a dump starts or just before a =
dump ends or both (which seems to be the case with the logs you found). =
Also, the elog level has to be set to info to get these messages in the =
elog.

3.       What's the meaning for below messages

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2846: FS: project      =
0x21700000098 - dumpSetup - dump_restore - [26]: client id 1214628720 =
snapnum 0 path / dumpRootInum 2 recSize 61440 lastDumpTime Mon Jun 30 =
23:30:16 2008 vol id 0x21700000098

CRN: Dump started from client <client id> on volume <vol id>. This =
volume was last dumped at <lastDumpTime> and is a full backup.

4.       What's the meaning for below messages.=20

Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] (start dump time =
1214884511 secs)

CRN: Dump started at time <start dump time>. This can be changed to a =
human readable format with a few unix commands that I dont remember now =
- think "date" may be one of them. This date/time should match the time =
of the elog entry. Also, this information can be got from the =
ndmpd.trace file in the SGA.

5.       What's the meaning for below messages.=20

Jun 30 23:58:11 onstor2 : 1:2:efs:INFO: 2856: FS: project      =
0x21700000098 - dumpStart - dump_restore - [26] dump LOG message: Mon =
Jun 30 23:58:11 2008 mapping (Pass I) [regular files] =20

CRN: Our dump implementation is based on the original BSD dump =
implementation with some optimizations, performance improvements and =
bugs :-) Dump runs in 4 passes (pass1 to pass4). The message above means =
that dump pass1 just started which is almost immediately after dump =
starts usually.

Happy Independence Day.
CRN: You too. Happy Independence Day.
=20

Thanks,

=20

Hong

=20

From: Xian Hong=20
Sent: Friday, July 04, 2008 8:38 PM
To: Shin Irie; Tim O'Callaghan
Cc: dl-cstech
Subject: RE: NDMP performance

=20

Thanks, Irie san. It's a good idea.

=20

Hong

=20

From: Shin Irie=20
Sent: Friday, July 04, 2008 8:13 PM
To: Tim O'Callaghan; Xian Hong
Cc: dl-cstech
Subject: RE: NDMP performance

=20

Hong,

=20

I think you can find real-world performance in Data Warehouse.  First, =
find customers who are using NDMP by searching NDMP issues in =
Salesforce. Then you will get S/N of the system and locate its SGA in =
DW.  elog should have messages of dump start and finish.  The volume =
information (size, # of inodes) is in sfinfo.xml.  DMA, array model and =
tape device are also in sfinfo.xml.  Only thing missing in DW is depth =
of directory tree.

=20

--

Irie

=20

=20

=20

________________________________

From: Tim O'Callaghan=20
Sent: Friday, July 04, 2008 7:54 PM
To: Xian Hong
Cc: dl-cstech
Subject: NDMP performance

Hong,

=20

NDMP performance is dependent on a number of factors, number of files, =
depth of directory tree size of volume etc - our approach to start =
streaming the data before the catalogue is complete does make an =
improvement but this is always going to be subjective because of the =
factors listed earlier - but you can make a significant improvement by =
turning off 'history' within the backup application.=20

=20

The drawback is that a restore will take longer but the actual backup =
will be much quicker.

=20

Regards

=20

Tim

=20

=20

=20



Tim O'Callaghan
Senior S.E.

ONStor, Inc.
office:  +44 1483 804825

mobile: +44 7767 435472=20

tim.ocallaghan@onstor.com <mailto:tim.ocallaghan@onstor.com>=20
http://www.onstor.com <http://www.onstor.com>=20

	 <http://www.onstor.com/images/footer/storage_mag_product_of_year.gif>=20

=09

=20

________________________________

From: Xian Hong=20
Sent: 03 July 2008 17:38
To: dl-cstech
Subject: NDMP performance

=20

Dear all,

=20

We indicate that we have tape backup performance advantage over NetApp =
in Sales guide.

=20

8) Tape Backup Performance

	Advanced NDMP implementation dramatically improves tape asset =
utilization.

	Decade-old technology consumes tape resources even when not streaming.

=09

=20

=20

Actually, customer always face poor performance of NDMP in high count =
file environment. If our NDMP advantage is true, that's really a big =
advantage.

=20

My question is :How well do we perform in this scenario? Do we have any =
NDMP benchmark ? I've searched intranet, but found nothing.

=20

Thanks,

=20

Hong

=20



------_=_NextPart_002_01C8DE57.3FA2AD48
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: NDMP performance</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Some answers inline (prefixed with CRN):<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Xian Hong<BR>
Sent: Fri 7/4/2008 5:27 PM<BR>
To: Shin Irie; Tim O'Callaghan<BR>
Cc: dl-cstech<BR>
Subject: RE: NDMP performance<BR>
<BR>
I've found a ndmp real case. &quot;AER&quot;<BR>
<BR>
<BR>
<BR>
Bobcat2<BR>
<BR>
SN: 0508040014<BR>
<BR>
Data warehouse: <A =
HREF=3D"http://cs-web/data/bysn/050/0508040014,onstor2,aer_atmospheric_en=
vironmental_research,_inc./">http://cs-web/data/bysn/050/0508040014,onsto=
r2,aer_atmospheric_environmental_research,_inc./</A><BR>
<BR>
Volume: Project<BR>
<BR>
Size: 3.6TB, 459857931 Blocks<BR>
<BR>
iNode: 4.3M<BR>
<BR>
Elog:<BR>
<BR>
Jun 29<BR>
<BR>
&nbsp;<A =
HREF=3D"http://cs-web/data/bysn/050/0508040014,onstor2,aer_atmospheric_en=
vironmental_research,_inc./elogs/2008/06/messages.20080629.gz">http://cs-=
web/data/bysn/050/0508040014,onstor2,aer_atmospheric_environmental_resear=
ch,_inc./elogs/2008/06/messages.20080629.gz</A><BR>
<BR>
Jun 30<BR>
<BR>
<A =
HREF=3D"http://cs-web/data/bysn/050/0508040014,onstor2,aer_atmospheric_en=
vironmental_research,_inc./elogs/2008/06/messages.20080630.gz">http://cs-=
web/data/bysn/050/0508040014,onstor2,aer_atmospheric_environmental_resear=
ch,_inc./elogs/2008/06/messages.20080630.gz</A><BR>
<BR>
<BR>
<BR>
Elog digest:<BR>
<BR>
<BR>
<BR>
Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1276: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - dump progress[11]: total records: 41415283; dumped: =
4128611; remaining: 37286672; estimated time remaining: 13:44:12; =
percent complete: 9%; throughput: 46325760 bytes sec<BR>
<BR>
Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1276: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - dump progress[11]: total records: 41415283; dumped: =
4128611; remaining: 37286672; estimated time remaining: 13:44:12; =
percent complete: 9%; throughput: 46325760 bytes sec<BR>
<BR>
Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1277: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [11] dump LOG message: Sun Jun 29 16:02:10 2008 dump =
progress[11]: total records: 41415283; dumped: 4128611; remaining: =
37286672; estimated time remaining: 13:44:12; percent complete: 9%; =
throughput: 46325760 bytes sec&nbsp;&nbsp;<BR>
<BR>
-----<BR>
<BR>
-----<BR>
<BR>
Jun 30 08:58:23 onstor2 : 1:3:efs:INFO: 2248: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [11] dump LOG message: Mon Jun 30 08:58:23 2008 dump =
progress[11]: total records: 41415283; dumped: 37345883; remaining: =
4069400; estimated time remaining: 2:2:26; percent complete: 90%; =
throughput: 34037760 bytes sec&nbsp;&nbsp;<BR>
<BR>
Jun 30 08:58:23 onstor2 : 1:3:efs:INFO: 2248: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [11] dump LOG message: Mon Jun 30 08:58:23 2008 dump =
progress[11]: total records: 41415283; dumped: 37345883; remaining: =
4069400; estimated time remaining: 2:2:26; percent complete: 90%; =
throughput: 34037760 bytes sec&nbsp;&nbsp;<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2846: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpSetup - =
dump_restore - [26]: client id 1214628720 snapnum 0 path / dumpRootInum =
2 recSize 61440 lastDumpTime Mon Jun 30 23:30:16 2008 vol id =
0x21700000098<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2846: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpSetup - =
dump_restore - [26]: client id 1214628720 snapnum 0 path / dumpRootInum =
2 recSize 61440 lastDumpTime Mon Jun 30 23:30:16 2008 vol id =
0x21700000098<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] (start dump time 1214884511 secs)<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] (start dump time 1214884511 secs)<BR>
<BR>
Jun 30 23:58:11 onstor2 : 1:3:efs:NOTICE: 2855: project snap create =
complete for dump_26 id 4<BR>
<BR>
Jun 30 23:58:11 onstor2 : 1:3:efs:NOTICE: 2855: project snap create =
complete for dump_26 id 4<BR>
<BR>
Jun 30 23:58:11 onstor2 : 1:2:efs:INFO: 2856: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] dump LOG message: Mon Jun 30 23:58:11 2008 mapping =
(Pass I) [regular files]&nbsp;<BR>
<BR>
Jun 30 23:58:11 onstor2 : 1:2:efs:INFO: 2856: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] dump LOG message: Mon Jun 30 23:58:11 2008 mapping =
(Pass I) [regular files]&nbsp;<BR>
<BR>
<BR>
<BR>
I'm confused with these logs and have some questions:<BR>
<BR>
1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How to interpret NDMP log =
messages? Is there any documents?<BR>
CRN: The messages are mostly self-explanatory. They indicate dump =
progress. Please note that multiple NDMP sessions may run at the same =
time - even on the same volume if they are partial and which is how LSI =
seems to do it - these have to be appropriately interpreted. Also, =
please note that none of these statistics was meant to be dead-on =
accurate - most of them approximate at best. There is also a low =
priority bug open about the stats being off under specific =
circumstances.<BR>
<BR>
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There is no start NDMP log =
messages and end log messages in the elogs.<BR>
<BR>
The first message is as below, but is not start message.<BR>
<BR>
Jun 29 16:02:10 onstor2 : 1:2:efs:INFO: 1276: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - dump progress[11]: total records: 41415283; dumped: =
4128611; remaining: 37286672; estimated time remaining: 13:44:12; =
percent complete: 9%; throughput: 46325760 bytes sec<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; And the last message is as below, but is not end =
message.<BR>
<BR>
Jun 30 08:58:23 onstor2 : 1:3:efs:INFO: 2248: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [11] dump LOG message: Mon Jun 30 08:58:23 2008 dump =
progress[11]: total records: 41415283; dumped: 37345883; remaining: =
4069400; estimated time remaining: 2:2:26; percent complete: 90%; =
throughput: 34037760 bytes sec&nbsp;&nbsp;<BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; According to <A =
HREF=3D"http://wiki.onstor.net/wiki/Troubleshooting_NDMP">http://wiki.ons=
tor.net/wiki/Troubleshooting_NDMP</A>,<BR>
<BR>
<BR>
<BR>
Alternatively, you could also search for start dump in the elogs to get =
dump start time. Note the volume name. Then search for dump is complete =
to get the end time and match the volume name. Obviously if you don't =
find the end of the dump, it was still running when the stats were =
collected.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; But there is only a start dump messages after a series =
NDMP process log messages.<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] (start dump time 1214884511 secs)<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;<BR>
<BR>
CRN: Since these large filesystems take a lot of time to dump, it is not =
uncommon to find NDMP running for days. Alternatively, it is possible =
for the elogs to roll over just after a dump starts or just before a =
dump ends or both (which seems to be the case with the logs you found). =
Also, the elog level has to be set to info to get these messages in the =
elog.<BR>
<BR>
3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What's the meaning for below =
messages<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2846: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpSetup - =
dump_restore - [26]: client id 1214628720 snapnum 0 path / dumpRootInum =
2 recSize 61440 lastDumpTime Mon Jun 30 23:30:16 2008 vol id =
0x21700000098<BR>
<BR>
CRN: Dump started from client &lt;client id&gt; on volume &lt;vol =
id&gt;. This volume was last dumped at &lt;lastDumpTime&gt; and is a =
full backup.<BR>
<BR>
4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What's the meaning for below =
messages.<BR>
<BR>
Jun 30 23:55:11 onstor2 : 1:2:efs:INFO: 2848: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] (start dump time 1214884511 secs)<BR>
<BR>
CRN: Dump started at time &lt;start dump time&gt;. This can be changed =
to a human readable format with a few unix commands that I dont remember =
now - think &quot;date&quot; may be one of them. This date/time should =
match the time of the elog entry. Also, this information can be got from =
the ndmpd.trace file in the SGA.<BR>
<BR>
5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What's the meaning for below =
messages.<BR>
<BR>
Jun 30 23:58:11 onstor2 : 1:2:efs:INFO: 2856: FS: =
project&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x21700000098 - dumpStart - =
dump_restore - [26] dump LOG message: Mon Jun 30 23:58:11 2008 mapping =
(Pass I) [regular files]&nbsp;<BR>
<BR>
CRN: Our dump implementation is based on the original BSD dump =
implementation with some optimizations, performance improvements and =
bugs :-) Dump runs in 4 passes (pass1 to pass4). The message above means =
that dump pass1 just started which is almost immediately after dump =
starts usually.<BR>
<BR>
Happy Independence Day.<BR>
CRN: You too. Happy Independence Day.<BR>
<BR>
<BR>
Thanks,<BR>
<BR>
<BR>
<BR>
Hong<BR>
<BR>
<BR>
<BR>
From: Xian Hong<BR>
Sent: Friday, July 04, 2008 8:38 PM<BR>
To: Shin Irie; Tim O'Callaghan<BR>
Cc: dl-cstech<BR>
Subject: RE: NDMP performance<BR>
<BR>
<BR>
<BR>
Thanks, Irie san. It's a good idea.<BR>
<BR>
<BR>
<BR>
Hong<BR>
<BR>
<BR>
<BR>
From: Shin Irie<BR>
Sent: Friday, July 04, 2008 8:13 PM<BR>
To: Tim O'Callaghan; Xian Hong<BR>
Cc: dl-cstech<BR>
Subject: RE: NDMP performance<BR>
<BR>
<BR>
<BR>
Hong,<BR>
<BR>
<BR>
<BR>
I think you can find real-world performance in Data Warehouse.&nbsp; =
First, find customers who are using NDMP by searching NDMP issues in =
Salesforce. Then you will get S/N of the system and locate its SGA in =
DW.&nbsp; elog should have messages of dump start and finish.&nbsp; The =
volume information (size, # of inodes) is in sfinfo.xml.&nbsp; DMA, =
array model and tape device are also in sfinfo.xml.&nbsp; Only thing =
missing in DW is depth of directory tree.<BR>
<BR>
<BR>
<BR>
--<BR>
<BR>
Irie<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Tim O'Callaghan<BR>
Sent: Friday, July 04, 2008 7:54 PM<BR>
To: Xian Hong<BR>
Cc: dl-cstech<BR>
Subject: NDMP performance<BR>
<BR>
Hong,<BR>
<BR>
<BR>
<BR>
NDMP performance is dependent on a number of factors, number of files, =
depth of directory tree size of volume etc - our approach to start =
streaming the data before the catalogue is complete does make an =
improvement but this is always going to be subjective because of the =
factors listed earlier - but you can make a significant improvement by =
turning off 'history' within the backup application.<BR>
<BR>
<BR>
<BR>
The drawback is that a restore will take longer but the actual backup =
will be much quicker.<BR>
<BR>
<BR>
<BR>
Regards<BR>
<BR>
<BR>
<BR>
Tim<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Tim O'Callaghan<BR>
Senior S.E.<BR>
<BR>
ONStor, Inc.<BR>
office:&nbsp; +44 1483 804825<BR>
<BR>
mobile: +44 7767 435472<BR>
<BR>
tim.ocallaghan@onstor.com &lt;<A =
HREF=3D"mailto:tim.ocallaghan@onstor.com">mailto:tim.ocallaghan@onstor.co=
m</A>&gt;<BR>
<A HREF=3D"http://www.onstor.com">http://www.onstor.com</A> &lt;<A =
HREF=3D"http://www.onstor.com">http://www.onstor.com</A>&gt;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.onstor.com/images/footer/storage_mag_product_of_year.g=
if">http://www.onstor.com/images/footer/storage_mag_product_of_year.gif</=
A>&gt;<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Xian Hong<BR>
Sent: 03 July 2008 17:38<BR>
To: dl-cstech<BR>
Subject: NDMP performance<BR>
<BR>
<BR>
<BR>
Dear all,<BR>
<BR>
<BR>
<BR>
We indicate that we have tape backup performance advantage over NetApp =
in Sales guide.<BR>
<BR>
<BR>
<BR>
8) Tape Backup Performance<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Advanced NDMP implementation =
dramatically improves tape asset utilization.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Decade-old technology =
consumes tape resources even when not streaming.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Actually, customer always face poor performance of NDMP in high count =
file environment. If our NDMP advantage is true, that's really a big =
advantage.<BR>
<BR>
<BR>
<BR>
My question is :How well do we perform in this scenario? Do we have any =
NDMP benchmark ? I've searched intranet, but found nothing.<BR>
<BR>
<BR>
<BR>
Thanks,<BR>
<BR>
<BR>
<BR>
Hong<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C8DE57.3FA2AD48--

------_=_NextPart_001_01C8DE57.3FA2AD48
Content-Type: image/jpeg;
	name="image001.jpg"
Content-Transfer-Encoding: base64
Content-Description: image001.jpg
Content-Disposition: attachment;
	filename="image001.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAmAUwDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDk/OHr
T0Yv06etZP2n3rTifFkHH93NYV6jhH3d2etk+Cp4qtL2vwxV7dyXvjcM01mKsAe/espbk7gQec1q
THCIT13Cs5SnSkk3e534fD4TH0ZyhT5HCz3buuz+4eQQODTUbeSM9KSadYZEDdGOKcse2VmHRhWK
xE1B83XY9KpkuEniY+yj7sXaSu+qunvc6Dwp4Rv/ABXcSiB1gtoTiSdxnB9AO5rrn+G+gRzfZH8U
RrdjgozIDn/dzmsv4Z+OdK0L7ZpeqzfZ1kl3xTEEr7g+ldVdeAfB3ii4mvNPv8TSnezWlwrjJ745
/pXoRd0mfG14qNWUVsm/zOOk8ASp4vTQRqSnfD5yz+V29MZ/rWH4q0J/C+tf2c9x9oPlLJvCbRzn
j9K9G8KWOo+EPGbaFeSi+t72HzLe6cncipkbQDnHWofH/juXRvEDaFHptrN59uoE0n3gXyP0pmR5
KJSxwoJPoBmgylThgQfQjFe1apPp/wAMvBMV1Y2MUly5WPc/V3YZJY9ccHijSLjT/if4KnnvrCKK
5UvFuQcowGQynrj2oA8U836/lR5v1/KvedITT7D4bQz39olxDBbHzVCDLhSRXl3iX4j2mpRWQ0TT
/sHkZBBVcFTjjA+lAHMLIWbA609nVByefSmNqkur6rcXlxs86X5mCLtHTHA7VnPdETMSeQ1c8uac
+W9kj2qHssLg1XlFSlNtaq6SXl3NFZNx4oMny7gcjvVGS9QptjGM8tSQz7ll54CZNW3K3NscsadH
m9ivebT17PdW8u//AAC95w9aPOHrWZ9p96PtPvWp55p+cPWjzh61mfafej7T70AafnD1o84etZn2
n3o+0+9AGn5w9aPOHrWZ9p96PtPvQBp+cPWjzh61mfafej7T70AafnD1o84etZn2n3o+0+9AGn5w
9aPOHrWZ9p96PtPvQBp+cPWjzh61mfafej7T70AafnD1o84etZn2n3o+0+9AGn5w9aPOHrWZ9p96
PtPvQBp+cPWjzh61mfafej7T70AafnD1o84etZn2n3o+0+9AGP8AavetPTtZiiTybg4Xs2On1rlf
tHvXT+G00x9OnuL6G3MvnrEkl+k5ttu3O0GH5vMz68baicFNWZ1YTF1cJV9rS3/Mtq+kpL5wuBxy
FzxUFzrMc91CqHbCrgsx71ot4VsptJktkWa01p9dXT40mYOkYZSQrSKcEd9wXOePeq1j4RsdR3T2
+rXS2ULTR3Dy2YWRWjiaT5EDkMCFIySOe1Zqgr3bbOyeb1HD2dKEYJu7styvq+owTCPyJQ2Cc4qx
Yazbm3C3EoV14ye4rOsNHsNV1SKKw1G4lsTGzzzPbpG9vjgbwzhACcYO/wDXir+oeD4dF8651PU5
PsAMIhe0gWeRzIpdcqHCgYU5IZucYzQ8PFwUOw4Z1iIYqWJSV5aNa2/M7bwfrHgG80KfSfFBRLg3
LyRTlGBCnph15H0PFdFoa/C7wlqg1i18RyyzRA7EaQuBkY4VVBP415u/w5SGa4SfXIYkFw9vbySe
VGG24y0geQFRlh90P3+lcnoUVrN4gjtr2OWeBTJuFupYEqDhjjny8jLY525xzWyVlY8qc3OTk+up
67cfF6wvPiTp+ptDJHpFrG8O4rlyG6vj0yBxWv4xuvh54muP7cfxIUvIYMRpCcbyMlcgrnrXld3o
FreRDUk+zWumxW7yzT6b5kiy7XVMRxTYcMC4zubBHI6VbtfBNrcaPIVuSXneK4tblo8OITDM+xk3
YDExepx60yT02Hx14O8e+Ek0jxBfHTbpQu7J24YcBlbBH5+tK/jfwb8PvCEul+H786ldtuKbTuy7
DG5mxgAegryXwl4d0+9fSrrWJZvIv0vQIEiyVaGPcCTuHrn6rjvUdx4bs4NItNVurySGwNpAzG1t
t8rvIZNpKM4HSM5IIHQAd6APWYviB4db4UnTZdVi/tNrNlaHY2d5JOOmK8MW5IUc9q6C48GWmntb
QX+rzLd3l61nbLBah0LYjKl2LgrnzFzgHGD1qC38JQNp9zJNqTyXlu8qNbWccch3ISCMPIrnpnKq
RjvwQADLg1BreZZFOSO3rWhKbfUD5trOiSn70TnHPtVPwXptp4g8UWun31ysEDK8jZ3fPtUttBAP
pz04B5zirVtpFnqccWoTXAsob68azs4rCBpU3rtBLeY4ZUO5SDyevAxUShd8y0Z10cXyU3RnHmg9
bdn3T6ERtLlD+9aKNf7zOMVHNfRxxeRA24Hl5MY3ew9qt6p4d07RobaHUNalj1C4ikkVRa7rdSsj
pguG3clDyEPUVV8D2mn6x4usrHVPNNtKHyiLksQhIB5GBxnI9Pejlb+JkuvCKapRtfq3d2+5flcq
/avej7V710DeHdIvrPw/b2V3cw6nqFnJKge3BjmKySYZ235Q7UxhVIqHUPBg0/QmvJtXthdpbJdN
A0kQVlYBgq/P5hfBHBQDOee9Wcxi/avej7V71Z0KO0/sPWdXuLRL2SxaBI7eYsI28xmBJ2EMSNvG
D371bGh2s8Q1C8F3pVvc3C20FrHD5zrIUVsncV2xkMMHk49epAMv7V70favet9/BMMN1YaXNqrjW
L5pkhjS3DQbo5GT5pNwYAlCchT1qWHwrp2rWHhwafdyQzXFjPdXskyKoKxuQSpZ9uRjABKggZJFA
HN/avej7V71u3XhHTrGG+vLnXWaytYYpSbWKOeUF3KbWCybVORnhjxSv4c03T9A8QzXlzNLc28Fp
cWTpDwEmIK7hu4Yg4I5A6gmgDB+1e9H2r3qx4fitW0rWtUubVLttPjhMdvKWEbGSTYS20hjgcjBH
410UngaG4uJrtr62s7EiHyxBKrAtJH5mV89oyEwehJYd89aAOV+1e9H2r3rcHg+0V9OtJNaL6hqU
80Fr9ngEluzI+wEybgdpPcKaJfBH2fRFu7jWLWK6a2FysTSRhCp5C8v5m4joNmM9+9AGH9q96PtX
vV/XdCsNN1O40qx1O6u9Tt5hCbd7PZ5rEgYjKs2Tz0IXj8q3LTwRY2+saHLdXz3Om3WoJZTxqIy/
mMMhf3cjYU4IJJBHoaAOU+1e9H2r3rfn8MWTaaNRW7eLToTcvJIluWnZFmWNBsL7ScsO4wM9ahuP
C+nadpTapqGr3SWbtALfyLNXkZZUZ1LqXAUgKcgE0AY32r3o+1e9V9asZtD1q70u4dHltn2MydDw
CP0Iqh9o96ANf7V70favesj7R70faPegDX+1e9H2r3rI+0e9H2j3oA1/tXvR9q96yPtHvR9o96AO
2/4V9ov/AEH9Q/8ABcn/AMeq5p3hW30iR5NN8Xa1ZvIu12gs1QsPQ4moorl9rLufR/UMP/L+L/zI
T4J0025tz4m1XyTJ5pj+wLtL4xux53XHerdz4eF5Kktz4016aRI2iVpLUMVRhhlGZ+hHBFFFL2su
4/qGH/l/F/5lay8GWGm3S3Nj4o1a2nXIWSGxVGGeDyJq3tLt4dOvJ72bX9TvryZQhubiGRZAg/hy
l0uR7HNFFHtZdw+oYf8Al/F/5lR9OnbUby+j8ba5bz3knmTm3s1jDt6kLMKyI/A2lxXK3MfiTVEn
V96yLp6Bg2c5z53XNFFHtZdw+oYf+X8X/mXX8OrJqaam/jPXWv0G1bk2oMijpgN5+e5qOTwtBLM8
sni/W3keZZ2drNSWkX7rk+d94Z4NFFHtZdw+oYf+X8X/AJk11oJvp4p7rxtr88sKssbyWoYoGGGA
Jn4yOD60y18NpYzJNaeMtcglji8hHjtApWPOdgIm4XPOKKKPay7h9Qw/8v4v/MgPg+zYxFvFWsEx
SmaPNkvySEglh++4JIHPsKtPoJlsGsH8ba81o+d0BtQUOTk5Hn4680UUe1l3D6hh/wCX8X/mUbfw
PplpOs9t4l1SGZchXjsEVhkYPIm9CRViw8LW+lxzJp/i7WrVJxtlWCzVA49DibnqaKKPay7h9Qw/
8v4v/Mry+B9MuEiSbxLqkiwpsjD2CEIuScD99wMkn8aLfwPplncJPbeJdUhmTO2SOwRWGRjgib0N
FFHtZdw+oYf+X8X/AJkkfhCzikt5I/FesI9spSBlslBiU5yF/fcDk9PU1OvhxU0w6YvjPXBYFSpt
haDy8E5I2+diiij2su4fUMP/AC/i/wDMgsPCFnpVz9p0/wAVavaT4K+ZBZKjYPUZE1T2vhxLKe4n
tfGWuwy3PM7x2gUy/wC8RPz1PWiij2su4fUMP/L+L/zII/CFnE9s8fivWEe1BEDLZKDFkknb++45
JPHrRF4Qs4XtXi8V6wjWmfs5WyUGLJz8v77jkk8UUUe1l3D6hh/5fxf+ZPe+HE1IOL7xlrlyHUIw
mtA25QcgHM3IB5qGTwhZyxyRyeK9YdJESN1ayUhlT7gP77kDsO1FFHtZdw+oYf8Al/F/5iWPg6y0
y6F1YeKtXtZ1BAkhsVRgD15E1WLbw6tneT3lt4z12G5uDmaaO1CvJzn5iJ8miij2su4fUMP/AC/i
/wDMjk8LW8tzFcyeLtaaeFzJHIbNSyMTksD53BJ5z61JD4eFvYPYQ+NNdjs3zugW1AQ565Hn45oo
o9rLuH1DD/y/i/8AMpT+B9Murh7i48S6pLO53NI9ghZj6k+dmtC50N7zyPtPjfX5vs7iSHzLYN5b
joy5n4PvRRR7WXcPqGH/AJfxf+ZDb+GIbWWCW38Ya3FJAXMTJZqDGW+9jE3Ge/rUdz4Qs7wSi58V
6xMJpfOkElkrb3xjcczcnBIzRRR7WXcPqGH/AJfxf+ZFceB9MvLh7i58S6pNM5y8klgjMx9yZqi/
4V9ov/Qf1D/wXJ/8eooo9rLuH1DD/wAv4v8AzD/hX2i/9B/UP/Bcn/x6j/hX2i/9B/UP/Bcn/wAe
ooo9rLuH1DD/AMv4v/MP+FfaL/0H9Q/8Fyf/AB6j/hX2i/8AQf1D/wAFyf8Ax6iij2su4fUMP/L+
L/zD/hX2i/8AQf1D/wAFyf8Ax6j/AIV9ov8A0H9Q/wDBcn/x6iij2su4fUMP/L+L/wAz/9k=

------_=_NextPart_001_01C8DE57.3FA2AD48--
